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REMARKS 



Applicant requests the entry of Preliminary Amendment A prior to publication and the 
first Office action on the merits of the application. The amendments detailed herein delete 
Appendix A and all references to Appendix A. Appendix B has been re-labeled as Appendix A. 
Applicant considers original Appendix A to be exemplary rather than essential. Applicant 
wishes to cancel Appendix A to reduce the publication burden on the Patent Office. 

Areas of the specification referring to former Appendices A and B have also been 
amended to be consistent with the deletion of Appendix A. 

Favorable consideration and an early allowance of this application is requested. Attached 
hereto is a marked-up version of the changes made to the application by the current amendment 
entitled "Version with Markings to Show Changes Made 11 . The Commissioner is hereby 
authorized to charge any fees that may be required during the entire pendency of this application 
to Deposit Account No. 19-1345. 



Respectfully submitted, 




James J. Barta, Jr., Reg. No. 47,409 
SENNIGER, POWERS, LEAVITT & ROEDEL 
One Metropolitan Square, 16th Floor 
St. Louis, Missouri 63102 
(314) 231-5400 



Express Mail Label No. EL 937975597US 
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VERSION WITH MARKINGS TO SHOW CHANGES MADE 
The paragraph beginning at page 6, line 6 is cancelled. 
The following paragraph was added after page 6, line 5: 
Brief Description of the Appendix 

A ppendix A, figure 1A illustrates the level of service provided during the 
fault detection and recovery interval for each of the failure modes. 

A ppendix A, figure 2A compares the requests serviced per second versus the 
requests received per second . 

The paragraph beginning at page 22, line 2 is amended as follows: 

The packets 1004 contain messages. In one embodiment, each packet 1004 
includes a collection of zero or more messages plus additional headers. Each message 
indicates some condition or action to be taken. For example, the messages might indicate 
a new network server has entered the ring network. Similarly, each of the client requests 
is represented by one or more of the packets 1004. Some packets include a self- 
identifying heartbeat message. As long as the heartbeat message circulates, the ring 
network is assumed to be free of faults. In the system 100, a token is implicit in that the 
token is the lower layer packet 1004 carrying the heartbeat message. Receipt of the 
heartbeat message indicates that the nearest transmitting ring member is functioning 
properly. By extension, if the packet 1004 containing the heartbeat message can be sent 
to all ring members, all nearest receiving ring members are functioning properly and 
therefore the ring network is fault-free. [See Appendix A for a description of packet 
and message formats in an exemplary embodiment of the protocol software 
according to the system 100.] 

The paragraph beginning at page 24, line 4 is amended as follows: 
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An exemplary embodiment of the system 100 is described below. Each client is 
an Intel Pentium II 266 with 64 or 128 megabytes (MB) of random access memory 
(RAM) running Red Hat Linux 5.2 with version 2.2.10 of the Linux kernel. Each 
network server is an AMD K6-2 400 with 128 MB of RAM running Red Hat Linux 5.2 
with version 2.2.10 of the Linux kernel. The dispatch server is either a server similar to 
the network servers or a Pentium 133 with 32 MB of RAM and a similar software 
configuration. All the clients have ZNYX 346 100 megabits per second Ethernet cards. 
The network servers and the dispatch server have Intel EtherExpress Pro/100 interfaces. 
All servers have a dedicated switch port on a Cisco 2900 XL Ethernet switch. Appendix 
A[B] contains a summary of the performance of this exemplary embodiment under 
varying conditions. 

Appendix A at pages 27-34 is cancelled. 

The paragraph beginning at page 35, line 1 is amended as follows: 
Appendix A[B] 

The paragraph beginning at page 35, line 5 is amended as follows: 

Our results demonstrate that in tests of real-world (and some not-so-real-world) 
scenarios, our SASHA architecture provides a high level of fault tolerance. In some cases, 
faults might go unnoticed by users since they are detected and masked before they make a 
significant impact on the level of service. Our fault-tolerance experiments are structured 
around three levels of service requested by client browsers: 2500 connections per second 
(cps), 1500 cps, and 500 cps. At each requested level of service, we measured 
performance for the following fault scenarios: no-faults, a dispatcher server faults, three 
server faults, and four server faults. Figure 1A[3] summarizes the actual level of service 
provided during the fault detection and recovery interval for each of the failure modes. In 
each fault scenario, the final level of service was higher than the level of service provided 
during the detection and recovery process. The rest of this section details these 
experiments as well as the final level of service provided after fault recovery. 
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The caption following the figure at page 35 is cancelled. 

The paragraph beginning at page 36, line 2 is amended as follows: 

In the first case, we examined the behavior of a cluster consisting of five server 
nodes and the K6-2 400 dispatcher. Each of our five clients generated 500 requests per 
second. This was the maximum sustainable load for our clients and servers, though 
dispatcher utilization suggests that it may be capable of supporting up to 3,300 
connections per second. Each test ran for a total of 30 seconds. This short duration allows 
us to more easily discern the effects of node failure. Figure 1A[3] shows that in the base, 
non-faulty, case we are capable of servicing 2,465 connections per second. 

The caption following the figure at page 38 is cancelled. 

The paragraph beginning at page 38, line 15 is amended as follows: 

As we see in Figure 2A[4], at 500 and 1,000 cps, we are capable of servicing all 
the requests. By the time we reach 1,500 cps, we can service just over 1,000. 2,000 and 
2,500 cps actually see worse service as the dispatcher becomes congested and packets are 
dropped, nodes must retransmit, and traffic flows less smoothly. The 1996 games saw, at 
peak load, 600 cps. That is, our capacity to serve is 1.8 times the actual peak load. In 
similar fashion, we believe our 1998 vintage hardware is capable of dispatching 
approximately 3,300 connections per second, again about 1.8 times the actual peak load. 
While we only have two data points from which to extrapolate, we conjecture that COTS 
systems will continue to provide performance sufficient to service even the most extreme 
loads easily. 



